后台功能设计的起点:权限方案设计分享

权限是一个公司信息系统的起点。我从入职以来就一直想要对公司后台的权限系统进行一个梳理(其实是老板要求的),苦于对后台和公司业务还不够了解,所以想法一直没能成型。终于,经过几个月断断续续的琢磨,我趁最近需求数量不多的时候,把权限的调整方案梳理了出来。

这次梳理公司后台的系统,我在原有权限系统的基础上引入了 公司组织架构,形成了 动态权限管理模式,使得公司的权限管理更加合理化。目前已经把方案提交给开发进行审核,希望可以最终落实。这里就先向大家汇报一下这几个月以来梳理权限的成果,给同样有权限体系设计问题的朋友们一点参考。

要设计权限,首先要对权限 已有的成熟方案有一定认识,其次要 对业务有深入的分析,才可以在业务的基础上有针对性的设计权限模型。

关于权限成熟方案,我查了很多资料,主要了解了一些关于 RBAC(Role-Based Access Control)权限模型的知识。加上在前司对SharePoint的权限分配方案有一定的了解,权限的知识基本就已经足够了(不够也没有更多了,找到一篇从产品的角度解释RBAC的文章,值得一读:请点击查看)

关于业务需求分析方面,我对公司后台的权限系统做了梳理。

因为公司对数据的保密要求很高,所以后台有大量查看项目、查看投资人的细致权限设置,但是 缺乏一致的管理方法,导致经常出现有需求无权限,或调动后权限没有及时清除的问题。公司后台主要是按照RBAC设置了权限体系,另外还根据项目服务小组的机制为每个项目单独设置了权限。后台RBAC的权限角色中,有部门角色、功能角色、临时团队角色等等,相对比较混乱。

现在这套系统面对一些问题:

权限角色太多,分类混乱。有大量临时建立弃而不用的分组;如果员工调换部门,需要逐个删除他已有的权限,再逐个赋予新部门的权限;如果部门领导更换,需要对部门内员工的所有成员的审批对象都进行调整。

为了解决上述问题,我尝试将公司的 组织结构信息引入权限管理的系统。

尽量以部门为单位分配权限,权限角色过多混乱的情况;出现员工部门调动或领导更换,会根据其部门更改自动重新分配权限;对无法按照部门分配的功能采取原有的权限分配模式,通过给不同的员工分配不同的角色实现,保证灵活性。

从上述的思路出发,我定义了新的权限管理需求。新的权限管理分为 部门权限制度和 非部门权限制度两种:

1、部门权限制度

部门权限分组默认按照组织结构图。

按照小组设置部门,部门分管理者权限和默认权限两种,默认权限为部门管理权限的子集。

若组织架构中的小组设置了管理者,则管理者默认拥有管理者权限。除管理者外,所有人加入小组后默认拥有默认权限。

(2)管理者权限包括

部门权限维护类:新建子权限组、默认权限维护、打破权限集成等权限(可以分配给部门领导使用,也可以掌握在超管手中统一分配) 审批类:所有报销、请假和购票的申请(若小组没有设置管理者,则小组成员所有审批事宜由上级层级中的管理者负责 ) 职能类:单个部门的全部权限

(2)权限维护类权限详细介绍

子权限组:部门内可以根据员工设置子权限组,根据子权限组,分配部门权限;默认权限维护:增删进入部门所默认拥有的权限;打破权限继承:使某位员工失去默认拥有的权限,为其单独分配权限。

2、非部门权限制度

组织方法参照原有RBAC权限管理;

超管可以为单个员工或小组开启非部门权限。

可以为非部门权限设置有效时间段;若员工调转部门,则所有非部门权限默认失效,需要超管审批以后方可重新生效。

这套规则可以基本解决原来的权限与部门没有关联的问题,以及权限分配混乱难以管理的问题。这仅仅只是产品从业务角度梳理出来的需求,具体实现还需要和开发商量以后解决。而且要真正能够落实实现还需要很漫长的过程。

这次设计方案给我最大的体会就是,设计复杂的功能最有效的手段还是 从具体是使用场景出发,使用场景决定业务逻辑,业务逻辑决定功能逻辑。我在最初设计的时候执着于寻找成熟的权限管理模式套用,后来发现这样生搬硬套不能提升后台权限分配的效率。在过后的几个月工作中,我接触到了不少分配权限的实际问题,比如不知道分权限给谁,或者分配出去的问题没有办法管理的问题。这些问题直接启发我引入了公司组织架构的概念,也便有了这套方案。

所以, 产品的设计与实现都服务于使用场景,才是真正好的产品,这一点对业务为导向的后台产品至关重要。与大家分享,也请大家多提意见。